【レポート】Startup Tech Talks: 仮想マシン、コンテナ、関数、Kubernetes on AWS の活用方法と展望 #AWSSummit
AWS Summit Tokyo 2018。Day3 で開催された『Startup Tech Talks: 仮想マシン、コンテナ、関数、kubernetes on AWS の活用方法と展望』についてレポートします。
スピーカー
- 九岡 佑介
- freee株式会社 プロダクト基盤本部 SRE, OSS Developer
セッション概要
AWS は以前から非常にスケーラブルで高性能なコンテナ管理サービス Amazon ECS を提供してきました。それに加え、2017年にラスベガスで開催した AWS re:Invent 2017 では、「地球規模にスケールする」とも謳われるコンテナオーケストレーションシステム『Kubernetes』のマネージドサービスである Amazon EKS が発表されました。また、世の中の Kubernetes クラスタの多くが AWS 上で稼働していることも事実です。このセッションでは、このような現状を踏まえて改めてスタートアップでの仮想マシン、コンテナ、関数、 Kubernetes on AWS の活用方法や動向についてお話しします。
コンテナを取り巻く環境
Right Abstraction. Right Tool
- 抽象レベルの違いを意識して、コンテナと関数の使い分け
- kubernetes は銀の弾丸ではない
Kubernetes の概要
- Google Borg というシステムが起源になっている
- コンテナオーケストレーションシステム
- 2014年に公開。プロジェクトとしては、まだ５年目
- 実はよく知られてないこと
- なぜ Kubernetes を使うべきでないか
スタートアップにおける課題のトレンド
- 生産性があがらない
- エンジニアが足りない
スタートアップにおけるサービス開発のトレンド
スタートアップにおける課題のトレンドが背景としてあり、以下のようなトレンドが生まれていると考える。
- マイクロサービスアーキテクチャ
- 生産性があがらない課題の解決策
- リモートワーク
- エンジニアが足りない課題の解決策
- コミュニケーションツールが充実してきた（chatwork/slack など）
- 必ずしも東京にいる必要はない
どの抽象レイヤー以降でこの課題を解決するか
- 物理マシン
- 仮想マシン
- コンテナ
- 関数
違いからみる、VM、コンテナ、関数
- 仮想マシンは、ひとつの物理マシン上で動いてる
- ついうっかり、１マシンで複数サービスをのせてしまい、切り出したくなり、コンテナに手をだす
- コンテナは、ひとつのコンテナイメージ
- ついうっかり、複数サービスをコンテナにのっけてしまい、この機能だけ切り出しくたくなり、関数に手をだす
- 関数は、ひとつの機能
- ついうっかり、複数機能をひとつの関数で・・・とはならない。関数はひとつの機能だから。
FaaS(Function as a Service） の新しさ
- 関数をデプロイの単位としたこと
- これまで悩んでいたことは、全部解決するんじゃないか。FaaS 最強！？
- 実際、FaaS で済むなら、FaaS がベストな選択
では、なぜ、関数じゃなくて、いまさらコンテナなのか？
運用ツールの違いからみる、VM、コンテナ、関数
- 仮想マシン
- マシンイメージから作成
- Ansible、Chef、Puppet ・・・など
- コンテナ
- コンテナイメージから作成
- Docker、ECS、Kubernets とか
- 関数
- スクリプトやバイナリから作成
- Lambda？、Serverless？、OpenWhisk?
ツールの違いは運用の違い
関数のマネジメントってどうしたらいいのか？ ”私はまだ即答できないからコンテナを使っている。”
まとめ：なぜ、関数じゃなくて、いまさらコンテナなのか？
- ツールがそろってなくて、運用が大変だから
- ただし小さなサービスで運用が簡単なら、FaaS を使うべき！
オーケストレーションがなぜいるのか
コンテナをデプロイするのにSSHではすまない
- コンテナが落ちたときに、他のノードの自動移行
- コンテナをロードバランサーにつなぐ
- サーバの余剰リソース内でコンテナ数を増やす
- オートスケーリング
なぜ Kubernetes を使うべきじゃないか
ECS の機能
- コンテナデプロイ
- IAM ロール対応
- ヘルスチェック
- サービスディスカバリ
Kubernetes の機能
- コンテナのデプロイ
- サービスディスカバリ
- ヘルスチェック
運用者目線での ECS メリット
- AWS 公式の専用の AMI
- マネージドサービス
- segment社の事例と OSS
- 日本での採用事例の多さ
- スコープが限られている（機能が限られている。ただし、今年かなり機能は強化された）
運用者目線での kubernetes のデメリット
- 公式 AMI がない
- マネージドサービスがない
- Kubernetes on AWSの事例少ない
- 日本での採用事例の少なさ
- スコープが広い
コンテナを使いたいだけだったのに、コンテナ外でこんなにがんばらないといけないのか・・ってなる。
- 情報が少ないとデバッグが大変
- 人を探すのも大変
Kubernetes のまとめ
- ECS より運用が難しい
- Lambda ほどうれしくない
- サーバー管理から完全に解放はされない
Kubernetes と EKS の使い所
ツールの違いは運用と適用領域の違い
- SAM + AWS
- コンテナ + ECS
- K8s Apps + kubernetes
Kubernetes の機能をよくみると、便利な機能もたくさんある
- コンテナのデプロイ
- サービスディスカバリ
- ロードバランス
- 便利な CLI アプリケーション
- 便利な API
- 便利なライブラリ
- 豊富な周辺ツール
- 拡張性
Kubernetes の拡張性をあらわす例
- metacontroller
- squash
- マイクロサービスのデバッガ
- Argo
- Kubernetes用のワークフローエンジン
- gloo
Kubernetes の使い所
- コンテナの運用をたすけてくれる
- Lambda や ECS より汎用的
- コンテナオーケストレーションというより、分散システムフレームワーク
- Kubernetes か、FaaS どちらかを選べってことではない
- 学習コストは高い
コンテナを「プロセス」とみたてると、Kubernetes は 「Linux」 というイメージ。
freee での利用例
- 新規サービスを Kubernetes 化
- 既存サービスは Docker から始めてる
- オンボーディング勉強会
- できるだけ作り込まない
- Kubernetes を構築して、運用するだけで結構なコストがかかる
- そのうえに、さらに作り込むべきではない
- Private PaaS のためのフレームワーク
EKS の特徴
- Kubernetes のコントロールプレーンをマネージしてくれる
- AWS IAM や VPC との統合
- Kubernetes の仮想ネットワークと VPC との接続を考えたりしなくていい
EKSの使い所
- Kubernetes on AWS は、すべて EKS を使うべき
コンテナの未来
- コンテナと Kubernetes という規格が定まる
- Kubernetes クラスタ自体の運用が簡単に
- Kubernetes 上のアプリ運用が簡単に
- Kubernetes 上で動いていることを意識せずにサーバーレスがりようできる
"「Linuxだからできない」ってこと、あまりないですよね？"
ECS はいらないこなのか？
- いいえ
- ECS + Fargate はサーバーレス Kubernetes on AWS のバックエンドになる
- 長期的にみると Kubernetes と ECS 両方わかると安心して運用できる。
まとめ
Right Abstraction. Right Tool
- 抽象レベルの違いを意識できるように
- 今後、正しいツールをえらべるように
- 将来的に FaaS の裏側は、Kubernetes になっていく
さいごに
コンテナ、Kubernetes、FaaS について、良いところばかりでなく使い所と、そうでない所、わかりやすいセッションでした！冒頭、「なぜ、Kubernetes を使うべきでないか」と言われたときは「え？どゆこと？」ってなりましたが、順を追って説明いただき納得の見解でした！
以上！大阪オフィスの丸毛（@marumo1981）でした！
